Part I: Designing Hardware for Future Integration: What Every Hardware Provider Should Know

by Kathy DeVito, Computer I/O

The information technology (IT) software industry continues to revel in advancements almost daily. However, not much has changed for those who integrate systems or write application software for embedded hardware. We still have to roll up our sleeves and deal with complex, low-level hardware integration and application access issues before we can start to work. But, there are some things that hardware providers can do to help reduce the pain of integration and, at the same time, give their hardware a competitive edge.

Traditionally, hardware providers have focused more on the design of the hardware itself, and less on how it will be used. ASIC, FPGA, and other hardware component providers often think their job is done once they build a register-level interface or, at best, an operating system-specific device driver. That means the device integration burden is passed to the developers and integrators who now have to manage in a proprietary, low-level, non-uniform environment. And, they have to solve problems that results-even though it may not be their core competence or primary application objective.

Developers and integrators are often forced to deal with a number of substantial issues:

• Dedicating engineering resources develop device drivers from scratch;

• Integrating proprietary application program interfaces (APIs) from multiple vendors;

• Troubleshooting poorly written software drivers;

• Designing systems based on sole source hardware and API packages;

• Significantly increasing the overall cost of development and time-to-market.

The custom integration effort to interface hardware with application software can be downright painful. Who wants to go through that again to modify and upgrade system hardware? Often, these systems are considered "untouchable." Once devices are integrated, they become permanent, inflexible components that frequently hold application and system integrators hostage.

While these integration issues have always been painful, there is an additional, more recent issue to deal with-the growing market for remote access. Many traditional local bus structures are being overtaken by TCP/IP-based Ethernet infrastructures and web-based access. So, hardware providers need to take these new technologies into consideration.

What should a hardware provider make of all this? Given that the competition for design wins is becoming ever more fierce, hardware providers need to differentiate themselves by facilitating device integration. And, that means considering the application software environment and usage issues right from the beginning of the design. It also may mean including network access support.

Application developers don't want to read through the register-level descriptions provided in component data sheets in order to work with data and control streams. Why should they worry about manipulating bits in registers or retaining virtual copies of a bit-mapped, write-only register? Why should reading data from one device be different from that of another-requiring a different include file, different function call, and different return code? Software developers need to operate on a higher programming level to be effective. Ultimately, they want uncomplicated access to data, control, and status.

App developers' perspective

The PC market has somewhat satisfied the application developer's need for a higher-level programming interfaces with the Wintel (Microsoft Windows and Intel processor) environment. Application developers have been able to leverage a common programming interface through the use of standard APIs for similar hardware devices. For example, DirectX provides standard APIs for voice, video, network connectivity, and keyboard and joystick devices.

The computer telephony integration (CTI) market has also adopted a standard to provide a higher-level application-programming interface (S.100 and TAPI). These standards enable different vendor telephony boards to play together in a single framework. For example, Dialogic provides a middleware product, CT-Media that provides an application development framework and supports products from multiple hardware vendors.

The manufacturing and industrial automation (IA) market has also developed standards for interface control with OLE for Process Control (OPC) which is based on the Microsoft Component Object Model (COM) infrastructure. With the distributed version, DCOM, applications can access hardware devices remotely over Ethernet local area networks (LANs).

The three development environments support specific devices and/or applications. Similar broad-base support is needed for other types of hardware cards and integrated circuits that don't lie squarely in these application spaces. For example, embedded devices like FPGAs, ASICs, SOC devices, and peripheral devices (found on digital signal processors and micro controllers) require a similar level of abstraction. Application developers need higher-level, standards-based interfaces to propel them forward, enabling them to meet faster time-to-market deadlines.

While application developers struggle with interfaces, system integrators face similar problems from a slightly different perspective. System integrators focus on the assembly of smaller building blocks (both software and hardware) in order to provide needed functionality at the customer level.

System integrators' perspective

While prudent software developers approach system design from a modular, reuseable standpoint (and hardware developers do the same), the junction between the hardware and the software components are frequently customized and not as reuseable as one might like. This complicates the job of the system integrator.

Think for a moment about a basic Analog-to-Digital Converter (ADC) hardware card (or integrated circuit). The system needs an ADC with a certain resolution and sample-rate capability. There are dozens of items on the market. The system integrator may design in one of them, but then that solution becomes a closely coupled module that can't easily be replaced. In order to use a new ADC component, a new interface may need to be written. Essentially, you need to do system-integration work again.

Beyond basic HW/SW interfaces, the computing platform and operating system also limits system integrator flexibility. A driver written to run on a PowerPC under VxWorks can't be easily transported to other platforms or operating systems.

Multiple versions of the software need to be issued and maintained.

In the enterprise, applications written once in Java will run on a multitude of platforms and operating systems. System integrators need the same flexibility in the embedded space that is already prevalent in the enterprise space.

For both HW/SW interfaces and platform and OS integration, hardware devices need to be more loosely coupled with their application counterparts in order to give system integrators more flexibility in solving customer problems (see Figure 1).

Hardware providers can help make their products more useable and more attractive by making sure that application developers and system integrators are isolated from implementation details related to access and communication. Essentially, hardware providers need to support some type of device software integration framework that eases access to the devices and exhibits the types of features listed below (see Figure 2).

What hardware providers need to keep in mind:

Provide high quality, fully featured software interfaces. When providing a hardware component, spend time on providing software interfaces that ease the job of the application developer and system integrator. Make sure your drivers work well and enhance your hardware product offering. After all, in many cases you're selling your hardware product to software and system integrators rather than your hardware peers.

Provide flexibility and modularity in software interfaces. As your hardware devices grow in complexity, consider maintaining modularity in the software interfaces to enable developers to focus on feature blocks of interest on an independent basis. Providing support for classes of devices is helpful. Also, multi-threaded, multi-user access can be desirable.

Develop uniform methods of access. Many of the functions required for hardware device application access are similar for different types of devices-even if the specific implementation of the functions varies from one device to another (an important distinction). Functions such as configuration, administration, and data streaming should be presented uniformly from one device to another-isolating the developer from implementation details.

Provide device and operating system isolation. With technologies like Java, you have the notion of write-once, run-anywhere software. In the device world, when it comes to device drivers, the notion of write-once, run-anywhere is a bit utopian. Nonetheless, the vision of device drivers that could be written once and run on multiple platforms is still highly desirable.

Strive for built-in network support. Network access for hardware devices could open up new markets enabling applications to execute in a distributed environment. Consider offering standard software support that makes your device network-accessible right out of the box, without the need for the software developer to build up a socket interface layer or some equivalent.

Adopt device-access standards (where they exist). Right now, there aren't many standard-device APIs. Industrial device manufacturers were one of the first to create and adopt a standard (OPC, for a specific class of industrial devices).

The future of system integration

In a perfect world, device implementation and communication details would become transparent.

A software application developer could access any device, at any time, from anywhere, using a standard interface method, without having to understand the low-level details of the device environment or the network connection being used.

An unrealistic nirvana? Not entirely. If you explore some aspects of this vision that are available today, you might find that the desired environment isn't as far away as it seems.

Kathy DeVito is head of product marketing at Computer I/O Corp. (Laurel, MD) and has been in the embedded technology industry for 15 years.

Part II: Programmable SOCs allow System-level Integration Without ASICs

by Martin Mason, Atmel Corp.

The trend in electronics has always been toward increasing the level of integration by combining more and more system functionality onto individual integrated circuits (ICs). Process technologies, EDA tools, and commercially available third-party intellectual property (IP) have evolved to such a point that, today, entire SOCs are relatively common. SOC designs cut system cost, size and power consumption, as well as increasing system reliability.

Although there are varying degrees of system-level integration on ICs, a true system on a chip has come to be defined as including three basic elements: a processor, memory, and logic. Integrating these three types of circuitry allows virtually all of the functionality of most systems to be implemented on a single chip.

Generally, system-level integration has been restricted to masked ASICs because integrating a processor, memory, and logic has required a custom implementation. Unfortunately, masked ASICs are accessible to only a small fraction of the design community. ASIC vendors simply won't accept designs without guarantees of annual volumes of hundreds of thousands of units per year or more.

Non-recurring engineering changes (NREs), such as IP and mask changes, can easily exceed a quarter of a million dollars for a single design. This means that only the highest volume designs can afford to create ASIC implementations of systems on a chip. In addition, ASIC design and fabrication cycles are too long for many products with short product life cycles, regardless of their volume, as the end products evolve so quickly. Finally, ASICs are inflexible. Any error or modification in the design will incur additional costly mask charges and another lengthy fabrication cycle for a re-spin.

Filling a market need

Thus, although most designers would like to do SOC implementations of their designs for power, space, and cost savings, the vast majority of them haven't had access to system-level integration. They have had to rely on some combination of discrete standard products, such as microprocessors, memory, digital signal processors (DSPs), and programmable logic. In essence, there is a hole in the market that hasn't been met by semiconductor vendors.

FPGA vendors have tried to address the need for moderate volume, quick-turn-around SOCs by offering ever larger FPGAs with gate counts exceeding one million system gates. Soft IP cores of processors and other shrink-wrapped IP functionality allow designers to implement the processor, memory, and logic on the FPGA without having to build all the functionality from scratch. However, these high density FPGAs, with their large relative die sizes, have several limitations including large physical area, high power consumption, and significant cost. In addition, the coarse-grained architecture of FPGA logic isn't the most efficient way to implement a processor core.

A microcontroller that costs $6 to purchase as a discrete solution might cost $60 to implement in a high density FPGA as a soft IP block. These devices are just too expensive for today's competitive markets. Thus, high density FPGAs have been used primarily for prototyping ASICs designs-which are then converted to ASIC implementations-or in applications where cost and power consumption are secondary considerations (such as cell sites and high-end networking infrastructure). The effort by FPGA vendors to deliver SOC technology into the hands of all designers via large FPGAs has been essentially a failure in applications where power, area, and cost are driving factors.

So the question is: How does the semiconductor industry bring system-level integration to designers who can't justify masked ASICs and can't use high density FPGAs due to power space or cost considerations?

The solution is to create hybrid products-programmable systems on a chip that offer system-level integration on a programmable off-the-shelf chip. A number of IC vendors have taken steps towards realizing programmable system-level integration. These new devices offer system-level functionality that includes a processor, memory, and programmable logic, without the NRE charges or lengthy fabrication cycles associated with ASICs.

They provide the high integration (low power, small space, low cost) of a masked ASIC with the low risk, flexibility and quick time to market of an FPGA.

Today, several IC vendors are now offering just this type of programmable SOC. Atmel developed the first RISC-based field programmable system-level integrated circuit (FPSLIC) in late 1999. FPSLIC devices are currently available in production quantities. Xilinx and Altera announced their own offerings in 2000, with silicon expected to be available in 2001. All three vendors have integrated a microcontroller with varying densities of programmable logic, memory, and peripherals on a single programmable IC. So, designers can take advantage of system-level integration, without the complex and risky issues associated with masked-ASICs. In fact, the SOC can be designed right on the designer's desktop.

Distinctions made

There are some significant differences between the various offerings. The devices from Xilinx and Altera are targeted at high-end broadband and telecommunications applications that require lots of digital signal processing. Altera's plans to include 200 MHz 32-bit processors from ARM and MIPS in its programmable SOCs, while Xilinx plans to use IBM's PowerPC core to deliver 405 Drhystone MIPS at 300 MHz. These devices are also expected to include large programmable logic arrays of 100K gates and higher and, based on early descriptions, it's clear that the products are targeted to designs that need a lot of processing power, and which may be relatively price and power insensitive.

Atmel's entry into the programmable SOC market is targeted toward commercial and industrial applications, such as portable, wireless and Internet applications, where low power, and moderate performance and cost are the driving requirements. These include personal digital assistants (PDAs) and their accessories, digital cameras, MP3 players, GPS modules, and wireless home networks that connect home appliances (security systems, climate control, white goods) to the end-user and/or manufacturer's service center via the Internet.

Atmel's FPSLIC programmable SOCs include the high-performance, low power 8-bit AVR microcontroller, with up to 36 KBytes of SRAM, as many as 40,000 FPGA gates, two UARTS, a two-wire serial interface, three timer/counters, and a real-time clock. Since the AVR core executes from the SRAM, it can deliver 20 MIPS performance at 25 MHz. This throughput is sufficient for image pre-processing and video compression/decompression. The FPSLIC's high throughput allows it to use burst-mode processing in which the AVR is kept in very low power standby mode most of the time, with very short bursts of high performance processing.

Burst-mode operation results in average power consumption that is substantially lower than running the microcontroller at a constant low frequency, while maintaining overall system throughput when required.

FPSLIC has a stand-by current of less than 100 microamps and a typical operating current of 2 to 3mA/MHz. This compares favorably with an ASIC solution and is significantly less than a discrete solution or large FPGA with several tens of milliamps in stand-by mode and several hundred milliamps during active current consumption.

The FPSLIC's on-board FPGA is based on Atmel's reconfigurable AT40K FPGA technology. Each FPGA cell is independently reconfigurable during system operation, without affecting any other cells. As a result, a single PDA accessory could be used to implement multiple different applications without ever disconnecting it from the PDA. A single PDA-mounted accessory could serve as an MP3 player, a digital camera, and a GPS module by pressing a button to activate reconfiguration of the FPGA on the FPSLIC (see Figure 3).

The advent of programmable SOCs is bringing system-level integration to all designers, regardless of their access to ASIC vendors.

This new technology will deliver highly integrated, high-performance development across a wide variety of future products. Determining which programmable SOC solution is the most appropriate, is a function of the cost, power consumption, and performance constraints of each design, as well as the design methodologies most familiar to the individual designer.

Martin Mason has been with Atmel Corp. (San Jose, CA) since 1993, most recently managing new product development for Atmel's programmable SLi group.

Part III: Enhancing Design Flows through System-on-a-chip Development Platforms

by Robin Bhagat, Palmchip Corp.

System-on-a-chip (SOC) design flows have suffered from extended delays as SOC designers struggle to identify, procure, integrate, and verify intellectual property (IP) cores in system designs. In contrast, SOC development platforms now provide a powerful starting point that dramatically accelerates design and simplifies system-level verification. By providing a complete set of integrated and verified IP cores needed for specific types of applications, SOC development platforms fit easily into existing flows and provide specific capabilities that help expedite design of SOC hardware and software.

In today's competitive electronics-based marketplace, where profit and loss are predicated on timely delivery of feature-rich products, SOC designers find themselves caught between shrinking project schedules and spiraling design requirements. In this climate, the concept of IP reuse holds special attraction, yet too often proves only a tantalizing mirage.

It's a buyer's market

Buying completed functions as IP cores should allow SOC developers to fill out a design with required features more quickly than if they were to build those functions from scratch. Even more important, developers hope to be able to focus limited time and scarce resources on building features and functions that will distinguish their product as unique amidst a crowded marketplace. In reality, however, designers find themselves forced to deal with real-world limitations that dim the industry's vision of IP reuse.

For SOC designers, IP integration and verification in system designs levy a significant burden if approached in an ad hoc fashion. Today's IP cores (other than processor cores) typically offer little documentation at the level needed to integrate the block into a system design and verify functionality at the system level. As a result, designers must spend considerable time dissecting core circuitry and analyzing its function to a sufficient depth to build interface logic and create test programs.

For typical bus-based cores, in particular, such efforts result in sub-optimal designs, because cores aren't provided with the arbitration logic and buffers needed to create interfaces at the system level. In fact, the requisite wrapper logic and tri-state buffers that SOC designers must introduce add considerable circuit overhead and result in slower performance, larger designs, and prolonged verification stages made more complex by the need to account for the multiple logical states associated with tri-state logic.

In contrast, SOC development platforms relieve the burdens associated with IP integration and system-level verification by providing pre-integrated and pre-verified cores used in specific types of applications. What's more, such platforms embed cores in an architecture designed with simplified interconnect mechanisms, which make it easy to enhance the base platform with the additional cores needed to meet the designer's specific application requirements. Furthermore, development platforms facilitate the HW/SW co-development strategies needed to complete hardware and software elements correctly and expeditiously.

With platform-based SOC approaches, designers proceed through development with their existing EDA tools-using synthesis and analysis tools as they normally would in any complex IC design project. Indeed, design platforms can provide key elements including the high-level models and verification test suites needed for critical synthesis and verification stages. What's more, accompanying platform development environments provide scripts and makefiles designed to help meld hardware and software development environments into a single, coordinated flow.

SOC development platforms enhance existing design flows and complement team-oriented SOC design methods. Platform-based methodologies accelerate the initial stages of design and speed later stages by simplifying system-level verification requirements.

Development platforms provide a fast start to new design efforts by providing a solid foundation for further development. Rather than spending valuable time identifying, qualifying, and acquiring standard interface cores, designers can leverage SOC development platforms and jump deep into the implementation phase. Just as evaluation boards often served as the nucleus of board-level designs, SOC development platforms provide complete reference designs that can be easily modified and enhanced.

Today, designers can choose two types of platforms: general-purpose platforms or platforms designed for specific applications. General-purpose platforms address the need for single-chip embedded systems comprising the usual complement of processor, memory, and peripheral functions as distinct cores-all pre-integrated and pre-verified. For example, general-purpose platforms such as Palmchip's SOC development platform offer complete system designs that include processor cores such as those from ARM, MIPS,ARC, and others, along with key peripheral functions including system timers, watchdog timer, interrupt controller, programmable I/O, memory controller, DMA controller, GPIO, alpha-numeric LCD controller, and UART. Similarly, application-specific platforms provide a completed design for particular applications that can be configured and modified as needed to meet target requirements-a micro-drive controller, for example. These application-specific development platforms enhance the general-purpose platforms with specific cores and features configured to meet specific requirements such as particular system bandwidth, bus widths, DMA channels, and memory configuration.

Interconnect mechanisms

Regardless of the type of platform they start with, SOC designers need to be able to supplement a platform-based design with additional cores that represent the designers' distinctive expertise and further differentiate the final SOC-based product for the company. At this stage, the platform's interconnect architecture determines the complexity of the integration task that faces the designer. Palmchip's platforms rely on the CoreFrame integration architecture to help simplify integration of additional cores. Rather than using buses-and incurring their additional overhead-the integration architecture provides interconnect mechanisms more suited to SOC design and the capabilities of current semiconductor process technologies.

Designed to meet package and manufacturing limitations of printed-circuit boards (PCBs), buses reduce the number of signal traces required between individual PCB components. By using tri-state circuits and arbitration logic, multiple logic signals share a smaller number of physical wires-thereby reducing the size of packages and connectors needed for PCB components and connectors, respectively. Today's semiconductor processes, however, provide multiple metal layers for interconnect with little impact on final manufacturing cost and die size. In integrating multiple components on a single chip, the previously advantageous reasons to multiplex signals on buses no longer apply. Indeed, current EDA synthesis and timing analysis tools have difficulties dealing with tri-state logic and multiplexed signals-further reducing the attraction of bus-based architectures in SOC design.

On the other hand, the integration architecture uses point-to-point and channel-based mechanisms that take advantage of process technology, simplify core integration, reduce circuitry overhead, and ease verification requirements compared with bus-oriented approaches (see Figure 4). Point-to-point mechanisms offer simple, dedicated pathways needed to access the registers used to control and maintain peripherals, for example. In this architecture, the Palmchannel provides the interconnect mechanism, while the controller transparently handles specific interface issues such as word-length differences. Using this approach, designers can link processor cores and peripherals by setting up these individual dedicated connections rather than by building bus interface and arbitration logic.

Recalling channel-based communications in traditional mainframes, channel-based core integration provides a high-speed data transfer mechanism needed to connect processor and memory cores.

In Palmchip's platforms, special channel hardware handles protocol, clock domain, bursting, and bandwidth translation between diverse cores using the channel-based Mchannel connections. For the SOC designer, this combination of point-to-point and channel-based mechanisms delivers a "plug-in" approach for core integration.

Competitive pressures

The efficient interconnect mechanisms in the architecture let designers realize the potential of IP reuse. Indeed, a development platform's combination of powerful interconnect architecture, pre-integrated and pre-verified cores, accompanying models and scripts, provides designers with the kind of comprehensive environment needed to create complex SOCs more effectively.

As companies face increasing competitive pressure for more sophisticated products, SOC development platform-based design methods will provide IC designers with a critical advantage in meeting time-to-market pressures.

Robin Bhagat is vice president of SOC technology at Palmchip Corp. (San Jose, CA) and co-chair of the VSIA Verification Development Working Group.